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Today  I  will  be  presenting  questions,  comments,  issues, 
anecdotes,  and  data  gathered  from  testing  EGI  integration  on 
several  different  platforms. 

There  will  be  questions  posed  within  this  presentation 

Some  are  rhetorical,  and  some  can  have  several  different 
answers  depending  on  the  individual  platform. 

My  background  is  navigation  software,  integration  and  test  on 
fixed  wing  tactical  aircraft. 

I  have  spent  the  last  several  years  testing  EGI  integration  into 
fixed  wing  tactical  and  also  rotary  wing  aircraft. 

This  presentation  is  generic  since  most  of  the  topics 
discussed  are  relevant  for  EGI  integration  on  many  platforms. 


Each  integration  is  different  and  has  its  own  challenges. 

Different  integrations  share  common  questions,  comments 
and  iessons  iearned. 

The  questions  most  often  asked  are  interspersed  throughout 
this  presentation. 

Performance  seen  during  test  is  simiiar 

Simiiar  goais  -  get  a  newer,  more  accurate  and  more  reliable 
product  to  the  fleet. 


Questions,  Opinions 
Concerns 

•  documentation 

•  training 

•  planning 

•  testing 

•  problems 

•  enhancing  characteristics 


How  often  does  the  EG  I  output  bad 
data  during  a  flight? 


The  first  five  are  the  recurring  issues  and  concerns.  All  are  important. 
They  are  not  listed  in  particular  order. 

Each  will  be  addressed  during  the  presentation. 

The  enhancing  characteristics  are  the  result  of  successful  EG  I 
integration. 

Training  and  documentation  are  the  foundation  for  good  EG  I  integration 
and  test.  The  risk  of  installing  new  avionics,  controls  and  displays,  and 
software  is  partially  mitigated  by  good  documentation  and  training.  They 
also  provide  a  basis  for  required  testing  -  in  the  lab,  during  ground  and 
flight  test. 

PIDS,  and  other  similar  documents  provide  the  rules  for  integrating  the 
EGI,  and  specs  and  TEMPS  define  what  items  need  to  be  tested,  how 
the  testing  will  be  accomplished,  and  what  the  exit  criteria  are. 

Time  for  test  is  generally  compressed  -  adding  regression  testing  for  new 
software  adds  time  and  money  to  the  program. 

Integration  and  test  always  have  some  problems  along  the  way. 
Documenting  problems  as  soon  as  they  are  discovered  helps  everyone 
get  a  clear  understanding  of  what  the  problem  is.  Once  understood, 
there  are  usually  several  ways  to  solve  a  problem. 

After  testing  for  a  while,  and  as  the  test  team  becomes  familiar  with  the 
EGI  integration,  most  of  the  “problems  and  issues”  are  replaced  by 
comments  such  as,  “that  is  really  better  than  the  old  system”,  or,  “that 
would  have  taken  a  lot  more  time  before”. 


liiPiiill 


Documentation 


When  should  it  arrive? 

Where  are  we  without  it? 

Why  is  the  documentation  always  late? 
How  is  it  organized? 

Can  it  make  or  break  a  program? 


Why  is  the  EG  I  worth  its  weight  in 
gold? 


Months  before  the  aircraft  arrives,  and  certainly  way  before  test.  All 
types  of  documentation  -  PIDS,  ICDs,  wiring  diagrams,  NATOPS,  users 
guides,  operator  manuals 

We  are  lost  without  good  documentation. 

Everyone  -  engineers,  maintainers,  and  aircrew  all  need  both  generic 
and  specific  documents. 

Sometimes  in  a  rush  to  get  the  software  out  the  door  for  test,  the 
documentation  lags.  This  puts  the  testers  at  a  disadvantage. 

Documentation  is  what  we  all  need  the  most  during  EGI  test. 

It  is  difficult  for  aircrew  to  write  changes  to  NATOPS  while  testing  system 
integration..  Using  old  NATOPS  procedures  is  sometimes  a 
disadvantage  when  using  EGls,  since  the  EGls  are  much  more  accurate 
than  some  of  the  older  nav  systems. 

There  are  different  levels  of  documentation.  An  overview  is  especially 
useful  at  the  beginning  of  a  program,  while  details  are  needed  to  fully 
understand  the  system  and  how  to  best  test. 

Different  personnel,  different  needs.  The  maintainer  needs  good  docs 
that  specify  such  things  as  torquing  procedures,  battery  changing 
schedules,  wiring  diagrams. 

Aircrew  need  information  on  how  to  best  use  the  system.  That  includes 
training  manuals  and  training.  Good  docs  definitely  help  a  program,  and 
lack  of  docs  hinder  test. 


Training 

Everyone  benefits 


-  desktop  trainers 

-  classroom 
-lab 

-simulators 

-  ground  test 


how  long  do  the  gyros  take  to  spin 
down  ? 


All  personnel  involved  in  test  require  training! 

There  are  many  ways  to  provide  timely  training.  It  can  start  with  good 
documentation. 

Desktop  trainers  are  very  useful  because  there  is  no  requirement  to  sign 
up  for  a  block  of  lab  or  aircraft  time.  Individuals  can  set  their  own  pace. 
Trainers  are  also  a  good  way  for  maintainers  to  “see”  possible 
installation/integration  issues  prior  to  aircraft  hardware  installs. 

Early  classroom  training  provides  a  forum  to  understand  the  concept  of 
the  EGl/aircraft  integration  and  a  good  time  for  questions  to  be 
answered. 

Although  labs  are  never  quite  work  the  same  as  the  aircraft,  lab  time  is 
still  a  good  way  to  practice  data  entry,  alignments,  navigation  mode 
changes,  waypoint  entry,  etc.  It  is  also  a  good  way  to  find  early 
integration  issues. 

Simulators  are  a  great  way  for  aircrew  to  get  familiar  with  data  entry, 
displays,  button  pushing,  and  increase  their  general  comfort  level  with 
the  new  system. 

Once  the  aircraft  arrives,  ground  test  is  essential  to  determine  readiness 
for  flight  test,  and  a  pre-verification  of  system  integration. 


High  Latitude  Aiignments^ 

•  Cold  Lake,  Canada 

•  56degrees  N,  both  ground  and  stored 
heading 

•  successful 


Aircraft  flew  from  Whidbey  to  Cold  Lake,  Canada. 

Both  Gyro  compass  and  stored  heading  alignments  were  performed. 


Human  Factors 


importance  of  “user  friendly”  interface 
aircrew/EGI  interface 
ease  of  data  input 
prevention  of  blunder  errors 
minimum  heads  down  time 

data  display 

-  format,  content,  alerts 

Why  does  initialization  data  need  to  be 
correct  ? 


Human  factors  is  the  comfortable  relationship  between  aircrew  and  aircraft. 

EGI  integration  should  be  as  transparent  to  the  user  as  possible.  The  mission 
of  the  aircraft  should  take  priority  -  not  the  EGI.  Input  and  output  data  should  be 
well  organized,  easy  to  access,  and  easy  to  understand. 

Data  input  should  be  logically  organized  -  avoid  nested  or  levels  of  data  entry. 
Define  early  in  the  program  the  default  hemispheres,  if  any. 

Should  input  data  such  as  latitude,  longitude,  date  or  time  default  to  some  pre¬ 
determined  values?  Should  data  for  input  be  stored  just  prior  to  shutdown? 

Would  an  ‘are  you  sure’  help  prevent  blunder  errors? 

The  design  of  the  system  should  allow  aircrew  to  input  only  what  is  required  at 
the  time. 

Strive  to  prevent  excessive  heads  down  time. 

Data  displayed  needs  to  have  instant  impact.  It  needs  to  be  in  readable  format 
(not  hex).  When  a  problem  arises,  we  all  want  to  know  what  the  problem  is,  not 
wait  until  the  aircraft  lands  to  look  up  some  hex  value  in  a  book.  (Again,  back  to 
documentation).  NO  ONE  wants  to  look  at  hex  data!!! 

When  designing  alerts,  be  careful  to  avoid  nuisance  alerts.  Example,  do  you 
inform  the  aircrew  every  time  GPS  aiding  is  lost?  Do  you  wait  1  minute?  Do 
you  wait  10  minutes? 


Does  there  need  to  be  a  backup  navigation  system?  How 
much  redundancy  does  the  aircraft  need? 

Should  the  different  EG  I  modes  or  the  backup  nav  system  be 
compared  for  position  and/or  velocity  differences  and  should 
alerts  be  displayed  if  a  threshold  is  crossed? 

Are  EG  I  navigation  mode  changes  automatic  based  on  validity 
bits  and/or  IBIT  fails?  Additionally,  if  more  than  one  EGI  is 
installed,  does  automatic  selection  for  prime  also  depend  on 
whether  one  is  aligning,  and  the  other  is  navigating? 

Since  many  aviators  fly  multiple  platforms,  adhering  to 
standard  navigation  conventions  and  display  formats  makes 
sense. 


Perform  analysis  for  antenna  placement  early  in  the  design 
stage.  If  multiple  avionics  or  stores  require  a  GPS  antenna, 
does  the  platform  require  separate  GPS  antennas,  or  would  a 
splitter  amp  suffice? 

Will  the  EGI  be  keyed  at  the  box,  or  from  somewhere  onboard 
the  aircraft? 

Would  it  be  beneficial  to  load  almanac  files  on  some  type  of 
1553  interface?  Is  it  necessary? 

Is  there  a  need  to  connect  the  EGI  to  some  type  of  master 
zeroize  switch,  or  would  pulling  batteries  be  sufficient  for  the 
platform? 


Test  Planning 


•  Be  prepared  for  the  unexpected!!! 

•  Scheduling 

•  Conflicts 

•  Flight  cards 

•  briefs 

•  debriefs 


How  heavy  is  the  EGI? 


The  unexpected  always  happens.  Be  as  prepared  as  possible. 

The  best  schedule  will  only  remain  that  way  for  a  microsecond. 

When  assets  are  shared,  there  will  always  be  conflicts  for  who  has 
priority.  Be  flexible  -  everyone  is  trying  to  complete  their  tasks. 

Try  to  generate  flight  cards  that  leave  no  margin  for  interpretation 
or  you  might  be  surprised  at  the  de-brief.  What  is  clear  to  you  may 
not  be  clear  to  anyone  else.  Leave  lots  of  room  for  aircrew 
comments.  We  were  testing  in-flight  alignments,  and  I  asked  the 
aircrew  to  fly  straight  and  level  for  the  first  30  seconds.  The  result 
was  an  entire  IFA  while  hovering.  Engineer  and  aircrew  had  a 
different  interpretation  of  straight  and  level. 

At  the  brief,  it  is  very  helpful  to  have  display  formats,  push  button 
layouts,  a  list  of  current  integration  problems,  and  NATOPS  at 
hand  in  case  any  last  minute  questions  arise. 

Debrief  as  soon  as  possible  after  the  flight.  Ask  questions.  Ask  for 
comments.  Ask  whether  any  problems  or  enhancing 
characteristics  were  observed  during  the  flight. 


•  what  data  to  collect 

•  what  data  to  reduce 

•  how  to  output  the  data 

•  inputs  for  reports  p 

How  do  you  pick  the  satellites  the  EG  I 
uses? 


Get  as  much  instrumentation  as  possible.  There  is  never  too 
much  data,  although  it  may  seem  that  way.  Try  to  instrument 
all  the  data  your  EGI  outputs  (1553,  synchros,  ARINC-429), 
and  all  input  data  into  the  EGI. 

Decide  what  needs  to  be  processed/analyzed  during  every 
flight,  and  try  to  automate  those  procedures. 

Inputs,  handshakes,  validities,  mode  changes,  switch 
positions  and  alerts  are  useful  in  determining  how  the  EGI  is 
operating. 

Aircraft  path,  altitude,  airspeed,  attitude  and  heading  are  also 
good  clues  as  to  what’s  happening  during  the  flight. 

Alignment  time,  type,  estimated  horizontal  and  vertical  error, 
figure  of  merit.  C/no,  and  bit  status  are  indicators  for  how  the 
flight  fared. 

Try  to  consolidate  data  as  much  as  possible.  Print  output  on 
change  only.  You  will  have  less  data  to  examine. 

Plots  are  great  for  the  big  picture. 


Cardinal  rules 


Get  a  good  product  to  the  fleet.  They  are  the 
user 

If  it  does  not  work,  fix  it 


•  believe  everything  the  aircrew  says 
happened,  every  time 

•  there  is  always  an  alternative 

•  you  cannot  be  over-prepared 

•  each  flight  is  a  lessons  learned 


How  many  satellites  do  we  need  to 
navigate? 


The  fleet  is  the  final  user.  Ensure  they  get  a  good  product. 

Strive  to  get  all  the  problems  fixed,  even  the  annoying  ones.  It 
makes  life  easier  for  aircrew  and  maintainers. 

No  matter  how  much  the  system  has  been  tested,  there  can 
always  be  surprises.  Always  believe  what  the  aircrew  says 
happened  during  a  flight.  Use  the  data,  if  possible,  to 
determine  why  it  happened. 

There  are  always  alternatives,  but  they  are  not  always 
obvious.  Keep  looking. 

There  is  no  such  thing  as  being  over-prepared. 

Every  ground  test  or  flight,  good  or  bad,  offers  valuable 
lessons  learned.  Use  the  results  to  better  the  system. 


The  Good 


The  accuracy  of  the  EGI  as  tested  was  better  ffia 
the  some  of  the  truth  data 

EGI  has  reduced  aircrew  workload  and  improved  SA 
precise  positioning  for  jamming  and  weapons 
Hovering  with  an  EGI  is  much  better  than  with 
Doppler  navigation  systems 
Better  en-route  navigation 
better  time  functions 
highly  accurate  and  reliable 

What  is  the  drift  rate  of  the  INS? 


I  have  used  both  differential  GPS  and  laser  data  to  verify  the 
accuracy  of  the  EGI. 

It  is  interesting  to  note  that  the  accuracy  of  the  EGI  was  better 
than  that  of  some  of  the  truth  data. 

There  is  a  reduction  of  aircrew  workload  when  the  EGI  is 
installed. 

Hovering  using  EGI  inputs  to  the  automatic  flight  control 
system  is  much  more  stable  than  hovering  using  doppler 
systems. 

En-route  navigation  is  much  better  due  to  the  accuracy  of  the 
EGI. 

Time  calculations  can  now  be  done  using  EGI  data,  rather 
than  manually. 

The  EGI  is  highly  accurate  and  reliable 


Problems 


Lack  of  satellite  acquisition  on  some 
GEM  cards  after  extended  periods  of 
non  use 


•  occasional  problems  during  alignment 

•  instrumentation  issues  with  ARINC  and 
1553 

Can  we  navigate  without  GPS? 


This  problem  appeared  on  each  of  the  EG  I  programs  I  have 
worked  on.  Pulling  batteries  helped  twice,  re-loading  software 
helped  once,  and  running  IBIT  cleared  the  problem  once. 

Very  rarely,  there  are  various  problems  that  abort  or  prolong 
alignment. 

1553  bus  problems  -  Once,  the  EGI  would  not  power  up  after 
several  days  of  ground  test.  Could  not  find  the  problem,  even 
after  checking  connectors,  wiring,  and  switches.  Finally,  when 
attempting  to  hook  up  a  1553  bus  analyzer,  we  found  the 
1553  bus  was  not  terminated  properly  (as  a  result  of  ground 
test). 

Instrumentation  system  can  affect  the  EGls  ARINC-429.  On 
one  program,  the  ARINC  wrap  fail  and  ARINC  transmission 
warning  get  set  when  the  EGls  are  powered  on  prior  to  the 
instrumentation  system.  The  ARINC  fails  trigger  an  INU  fail.  It 
took  a  while  to  convince  the  aircrew  that  the  EGI  was  “not 
broke”. 


Conclusions,  cont. 


eOlNSMalRsMonBror 


-  rarely  perplexing 

-  never  routine 

-  constantly  ‘in  motion’ 

Thank  you! 


a^MdUmi  (10  rrinltirtmria) 


Navigation  Initiaiization 

•  alignments 

-design  and  implementation 

-  how  is  the  EGI  initialized 

-  what  are  the  different  alignments 

-  when  are  they  used 

-  how  long  do  they  take 

-  how  do  we  know  when  alignment  is 
complete 


Alignments  are  the  beginnings  of  all  flights.  Make  them  work  -  and  they 
only  work  as  well  as  the  data  that’s  input! 

Ensure  they  are  implemented  correctly. 

Design  the  format  for  initialization  data  inputs  with  no  room  for  blunder 
errors. 

Only  allow  input  data  that  is  necessary  for  the  specific  alignment  type 
being  requested. 

During  training,  and  again  in  the  documentation,  be  sure  to  specify  what 
the  different  alignment  types  and  their  subsets  are  (stationary  and  in¬ 
motion). 

Document  when  to  select  a  specific  alignment  type. 

State  how  long  each  alignment  type  takes  to  complete. 

Talk  about  satellite  acquisition  times,  and  about  weekly  vs  annual  keys 

Display  in  easy  to  read  format  -  alignment  time,  quality  and  align 
complete. 

LET  there  be  no  doubt  that  alignment  is  complete. 


•  Issues 


Integration 


-  aggressive  test  schedules 

-  software  upgrades 

-  lack  of  aircraft  assets 

-  regularly  scheduled  maintenance 

-  lack  of  spares 

-  weather 


Will  the  EGI  align  on  a  ship  ? 


Most  schedules  are  compressed  -  to  the  right  for  start  of  test,  and  to  the 
left  for  completion  of  test.  It  is  very  difficult  to  balance  testing  needs  vs 
schedules,  especially  when  problems  arise. 

Software  upgrades  -  What  do  you  do  if  new  software  is  available  during 
developmental  test?  Stop  testing  now,  and  start  over  with  the  new 
software?  Plan  to  stop  when  testing  can  go  no  further,  or  at  a  point 
where  regression  test  would  be  greater  than  the  remaining  test?  There  is 
no  single  good  answer  to  this  question. 

If  new  EGI  software  is  to  be  loaded,  how  will  that  be  accomplished? 

What  happens  when  the  aircraft  is  down?  How  do  you  get  back  on 
schedule? 

Does  the  test  schedule  include  aircraft  maintenance  time? 

Are  there  spares  available  for  the  duration  of  test??? 

What  happens  to  the  test  schedule  when  the  aircraft  has  a  day  VMC 
only  flight  clearance  and  the  weather  un-cooperative  for  extended 
periods  of  time? 

Do  you  need  to  share  assets  or  facilities  during  test?  How  do  priorities 
get  set? 


Integration,  cont. 

•  More  Issues 


iiliiiiilp 


-testing  during  “off  peak”  hours 

-  distrust  of  new  technology 
-the  rumor  mill 

-  unusual  problems 

-  readiness  to  test 


How  often  does  the  EG  I  require 
calibration  ? 


When  the  aircraft  is  flying  during  the  day,  lots  of  ground  test  time  gets 
shifted  from  odarkSO  to  odarkSO.  Can  the  team  support  that  type  of  test? 

There  is  an  inherent  distrust  of  new  technology.  Why  upgrade  to  EG  Is 
when  the  “old”  system  worked  fine?  Aircrew,  engineers  and  maintainers 
all  need  time  to  get  to  understand  the  EGI  integration  in  their  aircraft. 
Only  after  time,  when  integration  issues  are  growing  smaller  and  the  EGI 
seems  to  be  performing  as  well  as,  (and  better)  than  the  old  system, 
does  the  distrust  slowly  dissolve. 

Sometimes,  problems  on  one  integration  cause  ripple  effects  on  other 
integrations.  During  catapult  testing  with  the  EGI,  the  aircrew  came  back 
saying  “the  EGI  broke  during  cats”.  They  had  heard  about  problems  on 
another  platform.  What  really  happened  was  a  keying  problem  that 
prevented  the  EGI  from  entering  into  Blended  mode,  that  had  nothing  to 
do  with  cat  shots. 

Has  the  problem  been  seen  on  other  aircraft,  or  on  other  platforms? 

Unusual  problems  -  GPS  week  rollover,  Y2K,  and  leap  day  testing  are  all 
behind  us  now!  We  sat  for  several  days  in  a  shielded  hangar  with 
simulated  satellite  signals  verifying  the  EGI  would  continue  to  operate  - 
and  it  did,  only  to  be  humbled  by  almanac  problems  after  that  fateful 
August  day. 

One  final  question  on  issues. ..Is  the  EGI  integration  really  ready  for  flight 
test?  How  many  open  problems  are  there?  Are  there  work-arounds  for 
integration  issues?  Will  the  program  benefit  from  flight  test 


